Gui for risk profiles

ABSTRACT

A memory device stores machine-readable instructions executable by a processor to cause the processor to graphically depict on a display device a first category of risk analysis data related to a plurality of insurance claims. The processor also causes the display to graphically depict a relationship between a first analysis result and a first benchmark value corresponding to the first analysis result, and graphically depict one or more user controls for selecting a second category of risk analysis data.

RELATED APPLICATIONS

This application is a continuation of application Ser. No. 13/351,989,filed on Jan. 17, 2012, currently pending, the disclosure of which ishereby incorporated by reference in its entirety.

FIELD OF THE DISCLOSURE

The present disclosure relates to assessing cost of risk for a businessentity and, in particular, to determining a risk profile related to thetotal cost of risk for an organization with the goal of identifying andmitigating key loss cost drivers.

BACKGROUND

The background description provided herein is for the purpose ofgenerally presenting the context of the disclosure. Work of thepresently named inventors, to the extent it is described in thisbackground section, as well as aspects of the description that may nototherwise qualify as prior art at the time of filing, are neitherexpressly nor impliedly admitted as prior art against the presentdisclosure.

Businesses employ a variety of strategies for assessing risks and costsassociated with operation, which include, among others, risks and costsrelated to insurance and, specifically, insurance premiums, retainedlosses, and administrative expenses. One metric used by organizations toquantify risk is the total cost of risk (TCOR). Methods of calculating,TCOR vary by organization, by industry, and by type of risk beingassessed. Additionally, the results of TCOR calculations are oftendifficult to interpret and/or fail to provide useful guidance foridentifying key loss cost drivers (i.e., the most significant losscosts) and decreasing the total cost of risk.

SUMMARY

A memory device stores machine-readable instructions executable by aprocessor. The instructions cause the processor to retrieve a first setof data from a database., the data including information about a numberof insurance claims. The instructions also cause the processor toperform an analysis of the first set of data to determine a first resultassociated with a first key performance indicator. The instructionscause the processor to obtain a first set of benchmark valuescorresponding to the first key performance indicator, and to compare thefirst result to the first set of benchmark values to determine therelationship of the first result to the set of benchmark values. Thedetermined relationship is sent to a display device. In variousembodiments, the key performance indicator may be one of: a percentageof workers compensation claims that include temporary total disability(m)) payments; an average number of days per TTD claim; an average valueof indemnity claims; a medical-to-indemnity conversion rate; a claimclosure rate for workers compensation claims; an average time between adate of loss and a date reported to a third party; a percentage of totalclaim payments attributable to medical costs; a percentage of medicalcosts attributable to pharmacy costs; a PPO penetration rate; apercentage of claims litigated; a percentage of total claim paymentsattributable to expenses; a percentage of total claim paymentsattributable to legal expenses; a trend relationship related to anactuarially based claim frequency rate; a variance related to anincidence rate of Occupational Safety & Health Administration (OSHA)claims; a variance related to a lost work date rate; and a loss ratecalculated based on claim frequency and claim severity.

In some embodiments, the instructions cause the processor to analyze oneor more second sets of data to determine one or more second resultsassociated with one or more second key performance indicators and toobtain one or more second sets of benchmark values against which tocompare each of the one or more second results. The determinedrelationships between each of the second results and the second sets ofbenchmark values are depicted on the display device.

The first key performance indicator may, in some embodiments, beassociated with a risk indication according to the comparison of thefirst result to the first benchmark value, and the risk indication maybe displayed on the display device. The second key performanceindicators may also be associated with respective risk indicationsaccording to the respective comparisons of each against the secondbenchmark values, and the risk indications displayed on the displaydevice.

In another embodiment, a memory device stores machine-readableinstructions executable by a processor. The instructions cause theprocessor to graphically depict on a display device a first category ofrisk analysis data related to a plurality of insurance claims, and tographically depict on the display device a relationship between a firstanalysis result and a first benchmark value corresponding to the firstanalysis result. Further, the instructions cause the processor tographically depict on the display device one or more user controls forselecting a second category of risk analysis data. The first analysisresult is one of the group consisting of: a percentage of workerscompensation claims that include temporary total disability (TTD)payments; an average number of days per TTD claim; an average value ofindemnity claims; a medical-to-indemnity conversion rate; a claimclosure rate for workers compensation claims; an average time between adate of loss and a date reported to a third party; a percentage of totalclaim payments attributable to medical costs; a percentage of medicalcosts attributable to pharmacy costs; a PPO penetration rate; apercentage of claims litigated; a percentage of total claim paymentsattributable to expenses; a percentage of total claim paymentsattributable to legal expenses; a trend relationship related to anactuarially based claim frequency rate; a variance related to anincidence rate of Occupational Safety & Health Administration (OSHA)claims; a variance related to a lost work date rate; and a loss rate.Depicting the relationship between the first analysis result and thefirst benchmark value may include depicting for each of one or more KPIsassociated with the first category at least a value calculated for theKPI and a comparison of the calculated value to a benchmark value.

In some embodiments, the depicted information includes for each KPIdepicting one or more historical values corresponding to the calculatedvalue. In some embodiments, the instructions cause the processor tographically depict for each KPI a relationship between each of the datasubsets related to the KPI and/or to receive a user input selecting oneor the plurality of data subsets and display the selected data subset inresponse to the received user input.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an embodiment of a system for generating arisk profile report in accordance with the present description;

FIG. 2 is a block diagram of another embodiment of a system forgenerating a risk profile report;

FIG. 3 illustrates a first aspect of an embodiment of a risk profilereport in accordance with the present description;

FIG. 4 illustrates a second aspect of the embodiment of the risk profilereport of FIG. 3;

FIG. 5 is a flow chart depicting a method of generating a risk profilereport in accordance with the present description;

FIG. 6 is a block diagram of an embodiment of a system for displayingdata associated with a risk profile;

FIG. 7 is a block diagram of another embodiment of a system fordisplaying data associated with a risk profile;

FIG. 8 illustrates aspects of a display generated by the system of FIG.6 or FIG. 7; and

FIG. 9 illustrates additional aspects of a display generated by thesystem of FIG. 6 or FIG. 7.

DETAILED DESCRIPTION

Although the following text sets forth a detailed description ofnumerous different embodiments, it should be understood that the legalscope of the disclosure is defined by the words of the claims set forthat the end of this patent. The detailed description is to be construedas exemplary only and does not describe every possible embodiment sincedescribing every possible embodiment would be impractical, if notimpossible. Numerous alternative embodiments could be implemented, usingeither current technology or technology developed after the filing dateof this patent, which would still fall within the scope of the claims.

It should also be understood that, unless a term is expressly defined inthis patent using the sentence “As used herein, the term ‘______’ ishereby defined to mean . . . ” or a similar sentence, there is no intentto limit the meaning of that term, either expressly or by implication,beyond its plain or ordinary meaning, and such term should not beinterpreted to be limited in scope based on any statement made in anysection of this patent (other than the language of the claims). To theextent that any term recited in the claims at the end of this patent isreferred to in this patent in a manner consistent with a single meaning,that is done for sake of clarity only so as to not confuse the reader,and it is not intended that such claim term be limited, by implicationor otherwise, to that single meaning. Finally, unless a claim element isdefined by reciting the word “means” and a function without the recitalof any structure, it is not intended that the scope of any claim elementbe interpreted based on the application of 35 U.S.C. 112, sixthparagraph.

FIG. 1 illustrates an exemplary embodiment 101 of a system 100 forassessing risk and generating a risk profile for an organization.Generally, the system 100 may include one or more client devices 102, anetwork 104, a server 106, and a database 108. Each client device 102may be communicatively coupled to the network 104 by one or more wiredor wireless network connections 112, which may he, for example, aconnection complying with a standard such as one of the IEEE 802.11standards (“Wi-Fi”), the Ethernet standard, or any other appropriatenetwork connection. Similarly, the database 108 and the server 106 arecommunicatively coupled to the network 104 via one or more connections114. As will be understood, the network 104 may be a local area network(LAN) or a wide-area network (WAN). That is, network 104 may includeonly local (e.g., intra-organization) connections or, alternatively, thenetwork 104 may include connections extending beyond the organizationand onto one or more public networks (e.g., the Internet). In someembodiments, for example, the client device 102, the server 106, and thedatabase 108 may be within the network operated by a single company(Company A). In other embodiments, for example, the client device(s) 102may be on a network operated by Company A, while the server 106 and thedatabase 108 may be on a network operated by a second company (CompanyB), and the networks of Company A and Company B may be coupled by athird network such as, for example, the Internet.

In any event, the server 106 includes a CPU or processor 116, arandom-access memory (RAM) 118 and, in an embodiment, a databaseinterface routine 120 for accessing records stored in the database 108.For example, the client device 102 may request records from the database108 via the server 106. The database interface routine 120 is a routine,executable by the processor I 36 and comprising a series of compiled orcompilable machine-readable instructions stored in a memory 121 in theserver 106. Alternately, the client device 102 may, in some embodiments,directly access records stored in the database 108, without the need ofthe server 106. The records stored in the database 108 may include claimdata 122, benchmark data 124, and other data 126, as described ingreater detail below.

Referring still to FIG. 1, the client device 102 includes a processor128 (CPU), a RAM 130, and a non-volatile memory 132. The non-volatilememory 132 may be any appropriate memory device including, by way ofexample and not limitation, a magnetic disk (e.g., a hard disk drive), asolid state drive (e.g., a flash memory), etc. Additionally, it will beunderstood that, at least with regard to FIG. 1, the database 108 neednot be separate from the client device 102. Instead, in someembodiments, the database 108 is part of the non-volatile memory 132 andthe data 122, 124, 126 ma be stored as data within the memory 132. Forexample, the data 122 may be included as data in a spreadsheet filestored in the memory 132, instead of as data in the database 108. Inaddition to storing the records of the database 108 (in sonicembodiments), the memory 132 stores program data and other datanecessary to create risk profiles and generate risk profile reports. Forexample, in an embodiment, the memory 132 stores a spreadsheetapplication 134 and a report application 136. The spreadsheetapplication 134 may manipulate, tabulate, and calculate data to generateinformation of the risk profile, while the report application maycompile the information generated by the spreadsheet application 134 andformat it for output to the user. Of course, there is no requirementthat the application 134 be a spreadsheet application. Instead theapplication 134 can be any application programmed to access data recordsfrom the database 108 and manipulate, tabulate, and calculate theinformation of the risk profile. In still another embodiment, theapplication 134 and the application 136 may be part of the same softwaremodule (i.e., a single application may retrieve the data, generate theinformation of the risk profile, and generate the report. Regardless,each of the applications 134, 136 is a routine, executable by theprocessor 128 and comprising a series of compiled or compliablemachine-readable instructions stored in the memory 132. Additionally,the memory 132 may store generated reports 138 in the memory 132. One ormore display/output devices 140 (e.g., printer, display, etc.) and oneor more input devices 142 (e.g., mouse, keyboard, tablet,touch-sensitive interface, etc.) may also be coupled to the clientdevice 102, as is generally known.

Turning now to FIG. 2, a second embodiment 150 of the system 100 isdepicted. Though similar in many respects to the embodiment 101 of thesystem 100 (depicted in FIG. 1), the embodiment 150 differs from theembodiment 101 in the routines stored in the non-volatile memories 121and 132 of the server 106 and the client device 102, respectively. Inthe embodiment 150, the memory 132 stores a web browser routine 152operable to communicate via the network 104 with the server 106 and, inparticular, with one or more routines stored in the memory 121 thereof.Specifically, a report data generation routine 154 retrieves data fromthe database 108 and performs manipulation, tabulation, and calculationof data to generate information of the risk profile. The report datageneration routine 154 may output the information of the risk profile toa report generation routine 156 in the server 106 that, in tarn, maygenerate risk profile reports. The risk profile reports may be stored inthe database 108, in the memory 121 of the server 106, or in as thereports 138 in the memory 132 of the client device 102. The routines 154and 156 may receive data from, and pass data to, the browser routine 152operating on the client device 102.

Regardless of whether the data generation routine is implemented in theclient device 102 (e.g., as routine 134) or the server 106 (e,g., asroutine 154), the data generation routine may be designed to processdata retrieved from the database 108. Specifically, the data generationroutine 134, 154 processes data to evaluate metrics in various riskcategories. In an embodiment, there are 12 categories of metrics, eachcategory related to losses, premiums and frictional costs, or claimadministration. The categories of metrics include: premiums—the cost ofinsurance or the sum of money paid, usually at regular intervals, for aninsurance policy; state pass-throughs—claim related expenses assessed bya jurisdiction (e.g., a state) and “passed through” to the insured bythe qualified self insurer or the insurance company; collateral-funds,in an amount calculated by actuaries based upon the reserves of openclaims and various development factors (e.g., credit sharing), fromwhich future liabilities created by claims may be paid; medicalstrategy—management of medical costs associated with claims;prevention—management (i.e., reduction) of claim frequency; informationmanagement—use of information systems to monitor claim frequency andseverity and claim reserve development; litigation management—managementof litigation costs associated with claims; disabilitymanagement—management or the processes related to returning an injuredperson to maximum medical improvement and returning them to work;actuarial processes—processes related to calculating liabilitiesassociated with open claims to confirm that adequate capital (e.g.,letters of credit or surety bonds) are reserved to cover futureliabilities; claims process—the process from claim reporting throughclaim closure, required to effectively and efficiently manage a claim;program structure—the structure of the insurance program and its effectson premium versus liabilities, administration costs, and jurisdictionalcompliance; and coverage—the terms of an insurance policy specifying theitems or hazards covered by the policy.

In each category, the specific metrics evaluated by the data generationroutine 134, 154 may include metrics derived from claim data (e.g., theclaim data 122 stored in the database 108) and/or metrics determinedaccording to survey responses (e.g., the other data 126 stored in thedatabase 108). The claim data 122 and the other data 126 (e.g., thesurvey responses) may be received from a client or insurer organizationin response to a request from the entity providing the risk profile. Forexample, in an embodiment, a consultant has access to the client device102. The consultant may request data from an insurance carrier orthird-party administrator (TPA), and may request information from theclient regarding non-claim aspects of the insurance program. In anotherembodiment, a user of the client device 102 has a more directrelationship with the insurance carrier or the TPA. For example, theuser may he an employee of the insurer or TPA. In this embodiment, theuser may have access to the necessary data and may need only to directthe data generation routine 134, 154 to a memory storage location (e.g.,one or more files in the database 108) in which the data required by theroutine 134, 154 is stored.

The data that will be used by the data generation routine 134, 154 maydiffer depending on the type of insurance and by the industry. Forexample, for certain businesses, it may be necessary to determinemetrics related to workers compensation claims only, while in otherbusinesses it may be necessary to determine metrics related to workers'compensation and also to general and/or auto liability coverages.

The data request may include a request for multiple runs of data. Eachrun of data may include different sets of claims, different data foreach claim, and/or different organization of data included in adifferent run. In an embodiment, the data are provided, in response tothe request, in one or more worksheets of one or more spreadsheetdocuments. A request for data may include, for example, a request for a“loss run” related to workers' compensation claims. The request mayspecify that the loss run data should include data for some time period(e.g., three full calendar years, two fiscal years, the most recent 36months, etc.), and may specify that the data should have current valuesand be sorted, for example, by loss year (i.e., the year that the lossoccurred). The request may also specify that the loss run data shouldinclude all claims, whether open or closed. In an embodiment, the datarequest specifies specific fields to he included among the loss rundata. By way of example and not limitation, the fields may (but need notnecessarily in all embodiments) include: claim number, claimant name,date of loss, date claim reported to employer, date claim reported tocarrier/TPA, claim status, date closed (if the claim is closed), date ofhire (i.e., the employee hire date), date of birth or age of theemployee, benefit state, jurisdiction, financials (broken out bymedical, expense, indemnity and then by paid/outstanding and totalincurred), location, occupation, department, cause of injury, source ofinjury, loss description, and body part affected.

A data request may also request a second run of data related to theworkers' compensation claims. For example, the data request couldrequest a payment summary report. Like the loss run, the data requestmay specify that the payment summary report should include data for aspecific time period (e.g., two years of payment information), and mayspecify that the payment information should be valued as of “current”and sorted by loss year. The request may also specify that the datashould include total summary of payments, and sub-totals by majorpayment category (i.e., indemnity, medical, and expense). Further, therequest may specify that the payment data include the number of claims(from the total claims) that include temporary total disability (TTD)payments and/or the number of claims with defense counsel and/orlitigation expenses.

Further, a data request related to workers compensation may also requesta “converted claims” loss run including information on claims that haveconverted from medical claims to indemnity claims. Once again, the datarequest may specify that the converted claims report include claim datafor a specific period (e.g., two years of claim information), mayspecify that the claim information should be valued as current andsorted by, for example, loss year, and may specify that the convertedclaims loss run should include all claims, both open and dosed, for therequested time period. In an embodiment, the data request specifiesspecific fields to he included among the converted claims loss run data.By way of example and not limitation, the fields may (but need notnecessarily in all embodiments) include: claim number, claimant name,date of loss, date the claim was reported, the claim status, the datethe claim was closed (if it is closed), the employee hire date, theemployee date of birth, the benefit state, jurisdiction, financials(broken out by medical, expense, and indemnity, and then by whether theclaim is paid or outstanding, and the total amount incurred), location,cause of injury, source of injury, loss description, and the affectedbody part.

Still further, a data request may include a request for program dataincluding, but not limited to: a description Of operations; aclassification code (e.g., the North American Industry ClassificationSystem (NAICS) code) that fits the operations; an audited financialreport; a latest actuarial report; a report of latest insurer lossforecasts for a retained layer by line of coverage; a collateral levelbreakdown by carrier, policy year, line of coverage, workers'compensation broken down by state, including any QSI states andassessments/surcharges by state; a report of the form of collateral(e.g., letters of credit, cash, etc.) and collateral estimated cost.; aTPA contract(s) and/or a breakdown to TPA names reflecting the policyyears and line(s) of coverage available from the TPA; a most recent TPAor carrier claim handling stewardship report; and/or casualty insuranceprogram details including: policy periods; retentions and limits perline of coverage and policy period; exposure workers compensation (e.g.,including payroll by state and class code per policy year); exposureliability (e.g., including revenue and auto count/miles driven perpolicy year); captive use description and captive financials; primarycasualty binder/financial program agreement; umbrella binders.

A data request may also include a request for information aboutpreferred provider network penetration and/or a request for amost-recent actuarial report, including, for example, claim frequencyrates by line of coverage for a specific time period (e.g., the mostrecent three years). Of course, the data request may, in Someembodiments, include requests for more, less, or different information,depending on the particular risk categories to be evaluated and/or theparticular metrics to be evaluated in each risk category.

The data received in response to the data request may be stored in thedatabase 108. Specifically, claim data (loss runs, etc.) may be storedas the claim data 122, while answers to qualitative survey questions,actuarial reports, and other data may be stored as the other data 126.

Among other tasks, the data generation routine 134, 154 may performtasks related to determining from the data provided one or more results,such as tabulating claims meeting certain criteria and calculatingvarious averages, percentages, cost totals, etc., as described below.Each of the one or more results may be associated with a key performanceindicator (KPI). The KPIs are metrics that are compared against one ormore benchmark values to determine the role played by the metric, andthe category with which the metric is associated, in terms of risk andloss.

Various examples of KPIs will be described in the following paragraphs,though their description is not intended to exclude other KPIs or toindicate that any one of the KPIs must be included in a particularembodiment, unless otherwise indicated. Additionally, the ordinaldesignation of the various metrics as “first,” “second,” “third,” etc.is not intended to indicate an order in which the metrics aredetermined, as the metrics are described in no particular order and, invarious embodiments, each may be included or excluded.

In an embodiment, the data generation routine 134. 154 determines afirst metric associated with disability management. The first metric maybe a percentage of workers' compensation claims that include TTDpayments as a part of the total claim count. For example, if the lossrun data include 3000 claims, and 612 of the claims include TTDpayments, then 20.4% of the claims include TTD payments. After thereport data generation routine 134, 154 determines the first metric, theroutine 134, 154 may determine one or more benchmark values and maycompare the result related to the first metric to the one or morebenchmark values. In an embodiment, the routine 134, 154 retrievesbenchmark data 124 stored in the database 108—from which benchmarkvalues may be calculated—and calculates the benchmark values therefrom.In another embodiment, the routine 134, 154 retrieves benchmark valuesfrom the benchmark data 124 stored in the database 108. For example, thebenchmark values may be stored in a table according to industry, timeperiod, geographical region, etc.

In any event, the routine 134, 154 compares the first metric to thedetermined benchmark values and, according to the comparison, assigns arisk indication corresponding to the metric. The routine 134, 154 maydetermine that the benchmarks applicable for a given set of data shouldresult in assignment of a negative indication if the first metric isgreater than 70%, a positive indication if the first metric is less than35%, and a moderate indication if the first metric is between 35% and70%, for example. While various ranges and benchmark values aredisclosed with respect to the metrics herein described, the ranges andbenchmark values are exemplary only. The ranges and benchmark values maybe any designated values stored as the benchmark data 124, includingvalues calculated by one or more computer processors, such as datacorresponding to an organization's peers within an industry, jobclassification, or jurisdiction.

In an embodiment, the data generation routine 134, 154 determines asecond metric associated with disability management. The second metricmay be an average number of TTD days per TTD claim. Determining theaverage number of TTD days per TTD claim may, in some instances, requiremultiple calculations. For example, if the loss run data include 612claims that include TTD payments, the average TTD days per TTD claim maybe calculated by dividing the total cost of TTD claims by the number ofTTD claims (e.g., 612), and then dividing the average TTD cost per TTDclaim by the average value of a TTD daily payment (e.g., $50). After thedata generation routine 134, 154 determines the second metric, theroutine 134, 154 may determine one or more benchmark values as describedabove, compare the result related to the second metric to the one ormore benchmark values, and assign a risk indication corresponding to themetric (e.g., negative if the result of the second metric is more than100 days, positive if less than 50 days, and moderate if between 50 and100 days).

In an embodiment, the data generation routine 134, 154 determines athird metric associated with the claims process category. The thirdmetric may be an average value of indemnity claims. To determine theaverage value of indemnity claims the data generation routine 134, 154may determine the total number of indemnity claims and the total amountof indemnity paid, and divide the latter by the former. After theroutine 134, 154 determines the third metric, the routine 134, 154 maydetermine one or more benchmark values for the third metric as describedabove, compare the result related to the third metric to the one or morebenchmark values for the third metric, and assign a risk indicationcorresponding to the third metric (e.g., negative if the result of thesecond metric is more than $20,000, positive if less than $10,000, andmoderate if between $10,000 and $20,000).

In an embodiment, the data generation routine 134, 154 determines athird metric associated with the claims process category. The thirdmetric may be an average value of indemnity claims. To determine theaverage value of indemnity claims the data generation routine 134, 154may determine the total number of indemnity claims and the total amountof indemnity paid, and divide the latter by the former. After theroutine 134, 154 determines the third metric, the routine 134, 154 maydetermine one or more benchmark values for the third metric as describedabove, compare the result related to the third metric to the one or morebenchmark values for the third metric, and assign a risk indicationcorresponding to the third metric (e.g., negative if the result of thethird metric is more than $20,000, positive if less than $10,000 andmoderate if between $10,000 and $20,000).

In an embodiment, the data generation routine 134, 154 determines afourth metric associated with the claims process category. The fourthmetric may be a conversion rate and, in particular, amedical-to-indemnity conversion rate. To determine the conversion rate,the routine 134, 154 may determine (e.g., by counting) the total numberof claims and the number of claims that were opened as medical only andclosed as indemnity claims, and divide the latter by the former. Afterthe routine 134, 154 determines the fourth metric, the routine 134, 154may determine one or more benchmark values for the fourth metric asdescribed above, compare the result related to the fourth metric to theone or more benchmark values for the fourth metric, and assign a riskindication corresponding to the fourth metric (e.g., negative if theresult of the fourth metric is more than 40%, positive if less than 10%,and moderate if between 10% and 40%).

In an embodiment, the data generation routine 134, 154 determines afifth metric associated with the claims process category. The fifthmetric may be a claim closure rate for workers compensation and,specifically, may be a 12-month claim closure rate (i.e., the percentageof claims closed within 12 months). To determine the claim closure rate,the routine 134, 154 may determine the total number of claims and thenumber of claims that were closed within 12 months, and divide thelatter by the former. After the routine 134, 154 determines the fifthmetric, the routine 134, 154 may determine one or more benchmark valuesfor the fifth metric as described above, compare the result related tothe fifth metric to the one or more benchmark values for the fifthmetric, and assign a risk indication corresponding to the fifth metric(e.g., negative if the result of the fifth metric is less than 50%,positive if more than 90%, and moderate if between 50% and 90%).

In an embodiment, the data generation routine 134, 154 determines asixth metric associated with the claims process category. The sixthmetric may be a claim report lag time. The claim report lag timeindicates the length of time that elapsed between the date of the lossand the date that the loss was reported to the insurer/TPA. To determinethe claim report lag time the routine 134, 154 may determine thepercentage of the total claims having a lag time of a certain period(e.g., 5 days) or less, or may determine the average lag time for all ofthe claims. After the routine 134. 154 determines the sixth metric, theroutine 134, 154 may determine one or more benchmark values for thesixth metric as described above, compare the result related to the sixthmetric to the one or more benchmark values for the sixth metric, andassign a risk indication corresponding to the sixth metric (e.g.,negative if the result of the sixth metric is less than 50% of claimsreported within the time period, positive if more than 90% were reportedwithin the time period, and moderate if between 50% and 90% werereported within the time period; or negative if the result of the sixthmetric is an average claim report lag time of 10 days, positive if 3days, and moderate if between 3 and 10 days).

In an embodiment, the data generation routine 134, 154 determines aseventh metric associated with the claims process category. The seventhmetric may be a characterization related to the effect on balance sheetof outstanding reserves. The characterization may be a response to aqualitative survey question included with the data request. For example,in an embodiment, the question is a multiple-choice question related tothe impact of the outstanding reserves on the balance sheet. The routine134, 154 may retrieve the response to the qualitative survey questionfrom the database 108 (e.g., from the other data 126). The routine 134,154 may determine one or more benchmark values for the seventh metric,each of which may correspond with one or more of the multiple-choiceanswers available to the person who answered the survey, compare theresult related to the seventh metric to the one or more benchmark valuesfor the seventh metric, and assign a risk indication corresponding tothe seventh metric.

In an embodiment, the data generation routine 134, 154 determines aneighth metric associated with the medical strategy category. The eighthmetric may be a ratio of medical costs paid to the total payments. Todetermine the ratio of medical costs paid to the total payments, theroutine 134, 154 may determine the total amount of medical costs paid,determine the total amount of medical, indemnity, and expenses, anddivide the former by the latter. After the routine 134, 154 determinesthe eighth metric, the routine 134, 154 may determine one or morebenchmark values for the eighth metric as described above, compare theresult related to the eighth metric to the one or more benchmark valuesfor the eighth metric, and assign a risk indication corresponding to theeighth metric (e.g., negative if the result of the eighth metric is morethan 75%, positive if less than 55%, and moderate if between 55% and75%).

In an embodiment, the data generation routine 134, 154 determines aninth metric associated with the medical strategy category. The ninthmetric may be a ratio of pharmacy costs paid to the medical costs paid.To determine the ratio of pharmacy costs paid to the medical cost paid,the routine 134, 154 may determine the total amount of pharmacy costspaid, determine the total amount of medical costs paid, and divide theformer by the latter. After the routine 134, 154 determines the ninthmetric, the routine 134, 154 may determine one or more benchmark valuesfor the ninth metric as described above, compare the result related tothe ninth metric to the one or more benchmark values for the ninthmetric, and assign a risk indication corresponding to the ninth metric(e.g., negative if the result of the ninth metric is more than 25%,positive if less than 10%, and moderate if between 10% and 25%).

In an embodiment, the data generation routine 134, 154 determines atenth metric associated with the medical strategy category. The tenthmetric may be a preferred provider organization (PPO) penetration rate.To determine the PPO penetration rate, the routine 134, 154 may retrievea survey response from the data provided in response to the data request(e.g., from the other data 126). After the routine 134, 154 determinesthe tenth metric, the routine 134, 154 may determine one or morebenchmark values for the tenth metric as described above, compare theresult related to the tenth metric to the one or more benchmark valuesfor the tenth metric, and assign a risk indication corresponding to thetenth metric (e.g., negative if the result of the tenth metric is lessthan 45%, positive if more than 75%, and moderate if between 45% and75%).

In an embodiment, the data generation routine 134, 154 determines aneleventh metric associated with the litigation management category. Theeleventh metric may be a percentage of the total claims that arelitigated. To determine the percentage of total claims that arelitigated, the routine 134, 154 may determine the number of claims thatwere litigated, may determine the total number of claims, and may dividethe former by the latter. After the routine 134, 154 determines theeleventh metric, the routine 134, 154 may determine one or morebenchmark values for the eleventh metric as described above, compare theresult related to the eleventh metric to the one or more benchmarkvalues for the eleventh metric, and assign a risk indicationcorresponding to the eleventh metric (e.g., negative if the result ofthe eleventh metric is more than 15%, positive if less than 5%, andmoderate if between 5% and 15%).

In an embodiment, the data generation routine 134, 154 determines atwelfth metric associated with the litigation management category. Thetwelfth metric may be a ratio of expense costs (i.e., costs associatedwith the claim other than indemnity and medical payments, such assurveillance, attorney fees, expert testimony, witnesses and summonses,autopsy, copying, arbitration, appeal bond costs, appeal filing fees,etc.) to total costs paid. To determine the ratio of expense costs tototal costs paid, the routine 134. 154 may determine the expense costspaid for all the claims, may determine the total costs paid for all theclaims, and may divide the former by the latter. After the routine 134,154 determines the twelfth metric, the routine 134, 154 may determineone or more benchmark values for the twelfth metric as described above,compare the result related to the twelfth metric to the one or morebenchmark values for the twelfth metric, and assign a risk indicationcorresponding to the twelfth metric (e.g., negative if the result of thetwelfth metric is more than 22%, positive if less than 7%, and moderateif between 7% and 22%).

In an embodiment, the data generation routine 134, 154 determines athirteenth metric associated with the litigation management category.The thirteenth metric may be a ratio of legal expense costs to totalexpense costs paid. To determine the ratio of legal expense costs tototal expense costs paid, the routine 134, 154 may determine the legalexpense costs paid for all the claims, may determine the total expensecosts paid for all the claims, and may divide the former by the latter.After the routine 134, 154 determines the thirteenth metric, the routine134, 154 may determine one or more benchmark values for the thirteenthmetric, as described above, compare the result related to the thirteenthmetric to the one or more benchmark values for the thirteenth metric,and assign a risk indication corresponding to the thirteenth metric(e.g., negative lithe result of the thirteenth metric is more than 50%,positive if less than 25%, and moderate if between 25% and 50%).

In an embodiment, the data generation routine 134, 154 determines afourteenth metric associated with the litigation management category.The fourteenth metric may be a response to a qualitative survey questionrelated to litigation management efforts. To determine the response tothe qualitative survey question, the routine 134, 154 may retrieve thesurvey response from the data provided in response to the data request(e.g., from the other data 126). The routine 134, 154 may determine oneor more benchmark values for the fourteenth metric, each of which maycorrespond with one or more of the multiple-choice answers available tothe person who answered the survey, compare the result related to thefourteenth metric, to the one or more benchmark values for thefourteenth metric, and assign a risk indication corresponding to thefourteenth metric.

In an embodiment, the data generation routine 134, 154 determines afifteenth metric associated with the litigation management category. Thefifteenth metric may be a response to a qualitative survey questionrelated to quality of litigation oversight. To determine the response tothe qualitative survey question, the routine 134, 154 may retrieve thesurvey response from the data provided in response to the data request(e.g., from the other data 126). The routine 134, 154 may determine oneor more benchmark values for the fifteenth metric, each of which maycorrespond with one or more of the multiple-choice answers available tothe person who answered the survey, compare the result related to thefifteenth metric to the one or more benchmark values for the fifteenthmetric, and assign a risk indication corresponding to the fifteenthmetric.

In an embodiment, the data generation routine 134, 154 determines asixteenth metric associated with the prevention category. The sixteenthmetric may be an actuarially based claim frequency rate and, inparticular, a claim frequency trend over a period of time. To determinethe actuarially based claim, frequency trend, the routine 134, 154 mayretrieve the data from data provided as a response to the data request(e.g., from the other data 126). After the routine 134, 154 determinesthe sixteenth metric, the routine 134, 154 may determine one or morebenchmark values for the sixteenth metric as described above, comparethe result related to the sixteenth metric to the one or more benchmarkvalues for the sixteenth metric, and assign a risk indicationcorresponding to the sixteenth metric (e.g., negative if the result ofthe sixteenth metric is a trend increasing by more than 15% over a giventime period, positive if the trend is decreasing, and moderate if thetrend shows an increase of less than 15% over the time period).

In an embodiment, the data generation routine 134, 154 determines aseventeenth metric associated with the prevention category. Theseventeenth metric may be an Occupational Safety & Health Administration(OSHA) incidence rate. In some instances, the seventeenth metric may bedetermined as a variance of the OSHA incidence rate from an industrywide rate (e.g., the rate according to the Bureau of Labor Statistics).To determine the OSHA incidence rate, the routine 134, 154 may retrievethe data from data provided as a response to the data request (e,g.,from the other data 126). After the routine 134, 154 determines theseventeenth metric, the routine 134, 154 may determine one or morebenchmark values for the seventeenth metric as described above, comparethe result related to the seventeenth metric to the one or morebenchmark values for the seventeenth metric, and assign a riskindication corresponding to the seventeenth metric (e.g., negative ifthe result of the seventeenth metric is more than 10% above the industryrate, positive if the trend is more than 10% below the industry rate,and moderate if the metric is between 10% below and 10% above theindustry rate).

In an embodiment, the data generation routine 134, 154 determines aeighteenth metric associated with the prevention category. Theeighteenth metric may be a lost workday case rate (i.e., the rate ofcases that include lost days of work). In some instances, the eighteenthmetric may be determined as a variance of the lost workday case ratefrom an industry wide rate (e.g., the rate according to the Bureau ofLabor Statistics). To determine the lost workday case rate, the routine134, 154 may retrieve the data from data provided as a response to thedata request (e.g., from the other data 126). After the routine 134, 154determines the eighteenth metric, the routine 134, 154 may determine oneor more benchmark values for the eighteenth metric as described above,compare the result related to the eighteenth metric to the one or morebenchmark values for the eighteenth metric, and assign a risk indicationcorresponding to the eighteenth metric (e.g., negative if the result ofthe eighteenth metric is more than 10% above the industry rate, positiveif the trend is more than 10% below the industry rate, and moderate ifthe metric is between 10% below and 10% above the industry rate).

In an embodiment, the data generation routine 134, 154 determines anineteenth metric associated with the prevention category. Thenineteenth metric may be a response to a qualitative survey questionrelated to management support for internal initiatives to improve safetyand prevention. For example, the question may request information abouthow a respondent would classify current initiatives focused on workerscompensation for auto liability or product liability, etc.). Todetermine the response to the qualitative survey question, the routine134, 154 may retrieve the survey response from the data provided inresponse to the data request (e.g., from the other data 126). Theroutine 134, 154 may determine one or more benchmark values for thenineteenth metric, each of which may correspond with one or more of themultiple-choice answers available to the person who answered the survey,compare the result related to the nineteenth metric to the one or morebenchmark values for the nineteenth metric, and assign a risk indicationcorresponding to the nineteenth metric.

In an embodiment, the data generation routine 134, 154 determines atwentieth metric associated with the actuarial category. The twentiethmetric may be a response to a qualitative survey question related to themethod by which reserves are established. To determine the response tothe qualitative survey question, the routine 134, 154 may retrieve thesurvey response from the data provided in response to the data request(e.g., from the other data 126). The routine 134, 154 may determine oneor more benchmark values for the twentieth metric, each of which maycorrespond with one or more of the multiple-choice answers available tothe person who answered the survey, compare the result related to thetwentieth metric to the one or more benchmark values for the twentiethmetric, and assign a risk indication corresponding to the twentiethmetric.

In an embodiment, the data generation routine 134, 154 determines atwenty-first metric associated with the actuarial category. Thetwenty-first metric may be a response to a qualitative survey questionrelated to the frequency of reserve reviews. To determine the responseto the qualitative survey question, the routine 134, 154 may retrievethe survey response from the data provided in response to the datarequest (e.g., from the other data 126). The routine 134, 154 maydetermine one or more benchmark values for the twenty-first metric, eachof which may correspond with one or more of the multiple-choice answersavailable to the person who answered the survey, compare the resultrelated to the twenty-first metric to the one or more benchmark valuesfor the twentieth metric, and assign a risk indication corresponding tothe twenty-first metric.

In an embodiment, the data generation routine 134, 154 determines atwenty-second metric associated with the actuarial category. Thetwenty-second metric may be a response to a qualitative survey questionrelated to how premiums and loss costs arc allocated to business units.To determine the response to the qualitative survey question, theroutine 134, 154 may retrieve the survey response from the data providedin response to the data request (e,g, from the other data 126). Theroutine 134, 154 may determine one or more benchmark values for thetwenty-second metric, each of which may correspond with one or more ofthe multiple-choice answers available to the person who answered thesurvey, compare the result related to the twenty-second metric to theone or more benchmark values for the twenty-second metric, and assign arisk indication corresponding to the twenty-second metric.

In an embodiment, the data generation routine 134, 154 determines atwenty-third metric associated with the data management category. Thetwenty-third metric may be a response to a qualitative survey questionrelated to data analysis tools for analyzing claims, policies, andexposure. For example, the question may ask a respondent to select aresponse describing how data consolidation tools are being used. Todetermine the response to the qualitative survey question, the routine134, 154 may retrieve the survey response from the data provided inresponse to the data request (e.g., from the other data 126). Theroutine 134, 154 may determine one or more benchmark values for thetwenty-third metric, each of which may correspond with one or more ofthe multiple-choice answers available to the person who answered thesurvey, compare the result related to the twenty-third, metric to theone or more benchmark values for the twenty-third metric, and assign arisk indication corresponding to the twenty-third metric.

In an embodiment, the data generation routine 134, 154 determines atwenty-fourth metric associated with the data management category. Thetwenty-fourth metric may be a response to a qualitative survey questionrelated to claim report generation tools. For example, the question mayask a respondent to select the response that best describes the easewith which claim data collection is accomplished. To determine theresponse to the qualitative survey question, the routine 134, 154 mayretrieve the survey response from the data provided in response to thedata request (e.g., from the other data 126). The routine 134, 154 maydetermine one or more benchmark values for the twenty-third metric, eachof which may correspond with one or more of the multiple-choice answersavailable to the person who answered the survey, compare the resultrelated to the twenty-fourth metric to the one or more benchmark valuesfor the twenty-fourth metric, and assign a risk indication correspondingto the twenty-fourth metric.

In an embodiment, the data generation routine 134, 154 determines atwenty-fifth metric associated with the data management category. Thetwenty-fifth metric may be a response to a qualitative survey questionrelated to exposure report generation tools. As an example, the questionmay ask a respondent to describe the ease with which exposure data arecollected. To determine the response to the qualitative survey question,the routine 134, 154 may retrieve the survey response from the dataprovided in response to the data request (e.g., from the other data126). The routine 134, 154 may determine one or more benchmark valuesfor the twenty-fifth metric, each of which may correspond with one ormore of the multiple-choice answers available to the person who answeredthe survey, compare the result related to the twenty-fifth metric to theone or more benchmark values for the twenty-fifth metric, and assign arisk indication corresponding to the twenty-fifth metric.

In an embodiment, the data generation routine 134, 154 determines atwenty-sixth metric associated with the data management category. Thetwenty-sixth metric may be a response to a qualitative survey questionrelated to the ease or difficulty of controlling data. To determine theresponse to the qualitative survey question, the routine 134, 154 mayretrieve the survey response from the data provided in response to thedata request (e.g., from the other data 126). The routine 134, 154 maydetermine one or more benchmark values for the twenty-sixth metric, eachof which may correspond with one or more of the multiple-choice answersavailable to the person who answered the survey, compare the resultrelated, to the twenty-sixth metric to the one or more benchmark valuesfor the twenty-sixth metric, and assign a risk indication correspondingto the twenty-sixth metric.

In an embodiment, the data generation routine 134, 154 determines atwenty-seventh metric. The twenty-seventh metric may be loss rate. Insome embodiments, the loss rate may be determined as a function of afrequency rate and a severity rate. The frequency rate may beactuarially developed to measure total exposure. For example, thefrequency rate may be determined, by calculating the total number ofclaims for a unit exposure (e.g., the number of claims per $1,000payroll). The severity rate may be actuarially developed to measure theaverage value of each claim (i.e., the total cost divided by the totalnumber of claims). The loss rate, then, may be the total cost per unitexposure (e.g., the cost of losses per $1,000 payroll). The loss ratemay be calculated using a historical loss run over a known period (e.g.,3 years, 5, years, 10 years. etc.). After the routine 134, 154determines the twenty-seventh metric, the routine 134, 154 may determineone or more benchmark values for the twenty-seventh metric as describedabove, compare the result related to the twenty-seventh metric to theone or more benchmark values for the twenty-seventh metric, and assign arisk indication corresponding to the twenty-seventh metric. Thebenchmark value(s) for the twenty-seventh metric may he based onhistorical performance of the organization, on industry peer informationstored in a database of public and/or proprietary information, or both.For example, the twenty-seventh metric may be calculated from data for arecent time period (e.g., the past three years) and compared to abenchmark value that is equal to the loss rate for the same organizationfrom a previous time period (e.g., the three years before last). Therisk indication may be assigned according to the trend for theorganization (e.g., negative if the loss rate is trending higher by morethan a certain amount, positive if the loss rate is trending lower bymore than a certain amount, and moderate/neutral if the loss rate issteady or not changing by more than the certain amounts). Alternativelyor additionally, the twenty-seventh metric may be calculated from datafor a recent time period (e.g., the past three years) and compared to abenchmark value that is equal to the loss rate, over multiple peerorganizations in an industry or organization type, for example, from thesame period. The risk indication may be assigned according to theindustry comparison (e.g., negative if the loss rate is higher than thepeer companies by more than a certain amount, positive lithe loss rateis lower than the peer companies by more than a certain amount, andmoderate/neutral if the loss rate is similar to the peer companies).

In an embodiment, the data generation routine 134, 154 determines atwenty-eighth metric. The twenty-eighth metric may be a measure of statepass-throughs. As described above, state pass-throughs are frictionalcosts such as taxes, fees, and the like, that arc paid to the state (orother governing jurisdiction). For example. Workers Compensationcoverage is federally mandated, but premium rates vary by state, jobclassification, and other factors. In many states, insurers are able towrite their own workers compensation plans, including determiningwhether to self-insure or insure through a deductible program (i.e.,through an insurance company). As a result of the many variables, it isdifficult to determine the optimal structure. It an embodiment, thetwenty-eighth metric may be an average state pass-through value per unitexposure (e.g., per $1000 payroll). In some embodiments, thetwenty-eighth metric may be further divided by geographic region, jobclassification, employee type, industry, etc. Thus, to determine thetwenty-eighth metric, the report generation routine 134, 154 perform oneor more of the following: determining the total amount of statepass-throughs paid to one or more jurisdictions, determining a totalpayroll value for each of the one or more jurisdictions, etc. After theroutine 134, 154 determines the twenty-eighth metric, the routine 134,154 may determine one or more benchmark values for the twenty-eighthmetric as described above, compare the result related to thetwenty-eighth metric to the one or more benchmark values for thetwenty-eighth metric, and assign a risk indication corresponding to thetwenty-eighth metric. For example, if the determined pass-through valueper $1000 payroll for a particular jurisdiction is higher for theorganization being evaluated than for the organization's peers, anegative risk indication may be assigned to the twenty-eighth metric.

In an embodiment, each of the risk indications may be a value associatedwith a cell in a spreadsheet, stored as a value in a record of thedatabase 106, etc. For example, a negative risk indication maycorrespond to a “0” value, a moderate risk indication may correspond toa “1” value, a good risk, indication may correspond to a “2” value, etc.In an embodiment, each risk Indication is associated with color (e.g.,red, yellow, green) so that a “dashboard” view may be presented to theuser in a report. Of course, any system of risk indications may be used,including by way of example and not limitation, numerical indications(e.g., numbers 1-3 or 1-5) or scales, written descriptions (e.g., bad,moderate, good), arrows (e.g., down, side-to-side, up), icons (e g happyface, sad face, etc.) or any other easily interpreted, indication.

Once the metrics have been evaluated, the benchmark values determined,the metrics compared to the benchmark values, and the risk indicationassigned according to the comparisons, the system 100 may generate areport of the risk profile assessment. The report may be generated bythe client device 102 running the report generation routine 136, asdepicted in FIG. 1, in an embodiment. In an alternate embodiment, thereport may be generated by the server 106 running the report generationroutine 156. In either embodiment, the report data generation routine134, 154, may call the report generation application 136, 156(respectively) and may pass data from the data generation routine 134,154 to the report generation routine 136, 156. The data passed mayinclude the determined metrics, the benchmark values, and the assignedrisk indications. Of course, in some embodiments, each of the reportdata generation routines 134, 154 and the report generation routines136, 156 may be part of a larger application or routine, and the usermay call each as desired by, for example, activating a user control(e.g., selecting a button or menu item) in the application.

FIG. 3 depicts one embodiment of a risk profile report 200 that may begenerated by the system. The risk profile report 200 may, in someembodiments, take the form of a chart 202 with rows 204 corresponding,to the KPIs and columns 206 corresponding to the relevant reported data.For example, the chart 202 depicted in FIG. 3 may include a row 204Arelated to the conversion rate KPI (i.e., medical-to-indemnityconversion rate). In a first column 206A, he chart 202 may include anindication of the metric (i.e., “Conversion Rate,” “Medical-to-IndemnityConversion Rate,” or something similar). The first column 206A may alsoinclude, in embodiments, a brief description of the metric or, inembodiments, the description may be in a separate column or may beomitted entirely). A second column 206B includes the results associatedwith the metric. In the example above, the results associated with theconversion rate in row 204A, ma 7include a simple value (e.g., 57%), avalue and an indication of the time period (e.g., 2009: 57%), or as moredescriptive statement (e.g., 57% of the indemnity claims in policy year2009).

A third column 206C includes an representation 208 of the assigned riskindication. In the depicted example chart 202 in FIG. 3, therepresentation 208 takes the form of a “stoplight” assessment. That is,the representation 208 is a circle filled in with red, yellow, or greenshading to indicate, respectively, a negative, moderate or positive riskindication. In FIG. 3, the respective shading is shown by crosshatched,horizontal, and vertical lines. The use of a stoplight assessment allowsa person viewing the report to get an immediate sense of which metricscould be significantly improved to reduce or optimize the risk profile.An explanation of the risk assessment may be provided in a column 206D.For example, the information in the column 206D may describe thecriteria used to assess the metric and/or the reason for the indication(e.g., “Conversion rate is significantly higher than the industry bestpractice of 37%.”)

The chart 202 may also include a column 206E making a recommendation forhow to address any increased risk associated with a particular one ofthe metrics. For example, a recommendation for reducing the conversionrate may be provided for the example above or, for another metric themetric may be recommended to be watched because of a trend. By way ofexample and not limitation, the recommendations may include studying oneor tore factors (e.g., pricing, premiums, etc.) and/or reviewingpractices and/or policies (e.g., claim review processes, litigationpolicies, etc.). The report generation routine 136, 156 may generate therecommendations according to one or more algorithms that receive asinputs one or more of the metrics and/or one or more of the assignedrisk indications. The recommendations in the column 206E may also bebased on combinations of the results. Because of this, in someembodiments, the recommendation may be provided outside of the chart202, for example in a “recommendation” section of the report 200. Therecommendation could also be included in one of the columns 206A-D,instead of in the column 206E.

In some embodiments, the report 200 may also include a categorized riskassessment. FIG. 4 depicts one form that a categorized risk assessmentcould take. In the depicted embodiment, a circular chart 210 includes asector 212 for each of the categories analyzed in the risk report. Inthe depicted chart 210, for example, sectors 212A-L represent the 12categories included in the risk report. Each of the sectors 212A-1,includes a corresponding indication 214A-L of the risk associated withthe corresponding category. As depicted in FIG. 4, the indication 214A-Lmay be a colored area of an outer edge 216 of each of the sectors214A-L, in an embodiment. In FIG. 4, for example, the edge 216 of eachof the sectors 214A-L is shaded to reflect a negative, moderate, orpositive risk assessment (represented as vertical, horizontal, orcross-hatched shading). In other embodiments, the entirety of the sector212A-L may be colored to reflect the risk associated with thecorresponding category. While the sectors 212A-L are depicted in FIG. 4as equally sized, the sectors 212A-L are sized according to relativerisk, ease of mitigating the risk, importance of the category as a lossdriver, and/or potential savings, in an embodiment.

Additionally, while FIG. 4 depicts the chart 210 having 12 categories,the chart may have as many or as few categories as desired or asanalyzed in the risk profile. For example, in an embodiment, the statepass-through category may be the only category considered in the report200. In another embodiment, the actuarial category may be the onlycategory considered in the report 200. Of course, the report 200 mayinclude any single category described above or any combination ofcategories described above with or without additional categories. In anembodiment, the report 200 includes KPIs corresponding to bothbrokerage-related categories (e.g., premiums, coverage, and programstructure) and loss-related categories (e.g., medical cost management,prevention, information management, litigation management, anddisability management).

The risk assessment attributed to each of the categories may be assignedaccording, to the risk indications assigned to the individual metricsassociated with the category and, in particular, may be assignedaccording to the most negative assigned risk indication associated withthe set of metrics, in an embodiment. For example, report lag time andconversion rate, each of which is associated with the claims processcategory, may have assigned negative and positive risk indications,respectively, in a particular report. Accordingly, the risk assessmentattributed to the claims process category may be assigned as negativebecause the report lag time is assigned a negative risk indication. Inanother embodiment, the outer edge 216 of each sector 212A-L may bedivided into a number of sub-sections corresponding to the number ofKPIs associated with the respective category, and each sub-section mayindicate the respective assigned risk indication of the KPI. Forexample, if only two KPIs (e.g., report lag time and conversion rate)are associated with a category (e.g., claims process), the edge 216 ofthe sector 212E may be divided into two sub-sections, one colored red(to indicate a negative assessment) and the other colored green (toindicate a positive assessment). As described above, the indicationsneed not be red, yellow, and green and, in fact, need not be colors atall. Instead, the indications could be any appropriate indicatoroperable to provide a user with an easily interpreted view.

Turning now to FIG. 5, a flow chart depicts a method 220 of assessing arisk profile. Generally, the method 220 starts with a request for claimdata being sent to the entity requesting the risk assessment (block222). The request may also include a request for data other than claimdata and, specifically, may include a request for answers to a varietyof questions characterizing and/or quantifying other aspects of thebusiness, as generally described above with respect to various KPIs.Alternately, the request may be omitted, in some instances, where thedata is already available to the entity performing the risk assessment.

The requested data and, optionally, other data (e.g., industry data,government data, etc.) may be received (block 224) and stored in thedatabase 108 (block 226). Depending upon the exact implementation,receipt and/or storage of the data may be performed by the client device102, the server 106, or a combination of the client device 102 and theserver 106. In an embodiment, the data is sent to the server 106 andstored in the database 108 by the processor 116 using the databaseinterface routine 120. In another embodiment, the client device 128(specifically, the processor 128) receives the data and stores the datato the database 108 directly. In still another embodiment, the clientdevice 128 receives the data and stores the data to the database 10$ viathe database interface routine 120 operating on the server 106.

In any event, having access to the stored data, the data generationroutine 134 (or 154) analyzes a first subset of the data to determine afirst result associated with a first KPI (block 228). For example, thedata generation routine 134 (or 154) may analyze a payment summaryreport, qualitative survey data, one or more actuarial reports, one ormore loss runs, etc. or a combination of these types of data todetermine the first result. In embodiments, the data generation routine134 for 154) may analyze a second subset of the stored data to determinea second result associated with a second KPI (block 230). Depending onthe particular KPI, determining the first result (and/or the secondresult) may require more than one determination and/or calculation. Forinstance, one KPI may require only a lookup of a survey response, whileother KPIs may require tabulating, claims to determine both a number ofclaims meeting a certain criterion and a total number of claims, andcalculating a percentage based on the tabulated values. The first andsecond KPIs may be KPIs associated with a single categories (e.g.,report lag time and conversion rate, both associated with the claimsprocess category) or with different categories (e.g., conversion rateand percentage of claims with TTD payments, the latter of which isassociated with the disability management category).

The data generation routine 134 (or 154) then compares the first andsecond results to corresponding first and second benchmark values (block232). As will be appreciated based on the foregoing description, each ofthe first and second benchmark values, instead of being a single value,may be a set of values. That is, the data generation routine 134 (or154) may compare the first result to a single value, as might be thecase if there are only positive or negative risk indications available(e.g., compare the first result to the benchmark value to determine ifthe first result is above or below some value). Alternately, the datageneration routine 134 (or 154) may compare the first result to multiplevalues, as might be the ease if there are more than two risk indicationsavailable (e,g., compare the first result to a first value to determineif the first, result is less than a first value, if it is then give apositive risk indication; if not, compare the first result to a secondvalue to determine if the first result is greater than the second value,if it is then give a negative risk indication; if it is not, give amoderate risk indication). The data generation routine 134 (or 154) thenassigns risk indications to each of the first and second resultsaccording to the first and second comparisons (block 234).

In some embodiments, a recommendation is generated according to the riskindication or risk indications (block 236) and/or, in some embodiments,according to the first and/or second results. The generation of therecommendation may be accomplished by the data generation routine 134(or 154) or by the report generation routine 136 (or 156). The reportgeneration routine 136 (or 156) generates a report of the risk profileassessment (block 238) according to the assigned risk indications and,in some embodiments, the generated recommendations. The report may bestored on the client device 102 or in the database 108.

In another embodiment, a routine may provide a user interface that bothfacilitates the analysis of one or more metrics and provides a means foraccessing the data associated with the metric(s). FIGS. 6 and 7 depictembodiments 300 and 310 a system including the user interface routine.The embodiments 300 and 310 generally conform to the embodiments 101 and150 depicted in FIGS. 1 and 2, but differ at least with respect to theroutines stored in the non-volatile memories 132 (on the client device102) and 121 (on the server 106). In particular, in the embodiment 300depicted in FIG. 6, the non-volatile memory 132 includes a datageneration and viewing routine 302. The routine 302, when executed bythe processor 128, is operable to retrieve data from the database 108(possibly via the database interface routine 120 on the server 106) andto determine one or more results associated with one or more KPIs.Additionally, in embodiments, the routine 302 is further operable todisplay the result over different time periods (e.g., over the past 1,2, 3 years), to display the result at each of several times (e.g.,October, November, December; or October 2009. October 2010, October2011), to display a trend associated with the result, and/or to displaythe result relative to one or more benchmark values (e.g., as a markerplaced along a divided continuum; as a bar graph with various referencevalues noted; etc.). The benchmark values may be stored locally on theclient device 102. In an embodiment, the benchmark values may be updatedoccasionally via the network 104. Additionally, in some embodiments, thedatabase 108 may be communicatively coupled to the client device 102,and/or the server 106 may be omitted.

The routine 302 further enables a user to see the data from which theresult was determined, in an embodiment. For example, the routine 302may receive a user input (e.g., a selection of a button, menu item, orfeature of the graphical user interface) and, in response to the input,to display the associated data. Selection of a graph may open a newwindow (or replace the content of a current window) with a display ofthe data used to create the graph. In an embodiment, selection of aparticular data point on a graph (e,g, a data point for the month ofJuly) may cause the data for the month of July to be displayed to theuser.

For some KPIs, the graphical information may depict subcategories ofdata, in an embodiment. As one example, an average indemnity cost may bedisplayed for each of several causes (e.g., slip/fall, caughtin/between, struck/injured by, strain/overexertion. etc.). Additionallyor alternatively, the average indemnity cost may be displayed for eachof several months. As another example, an average indemnity cost may bedisplayed for each of several body parts injured (e.g., skin,bone/joint, soft tissue, etc.). As yet another example, an averageindemnity cost may be displayed as a breakdown according to theorganization (e.g., distributors, retail, manufacturing). Of course, theKPI for which results are displayed is not limited to average indemnitycost, but may include any KPI calculable from the available dataincluding, without limitation, KPIs associated with the claims process,litigation management, disability management, and/or medical costmanagement categories.

In the embodiment 310 depicted in FIG. 7, the data generation andviewing functionality is implemented by the cooperation of a browser 312operating on the client device 102 and a data generation and viewingroutine 316 operating on the sever 106. Specifically, in an embodiment,the results associated with the KPI or KPIs may be generated in the datageneration and viewing application 316 and may be formatted fortransmission to the browser 312 which, in turn, may display theformatted results to the user. In an alternate embodiment, the a plug-in314 may be installed with the browser, as generally known, and mayimplement the functionality of the data generation and viewing routine316 or cooperate with the routine 316 to display the results.

FIGS. 8 and 9 illustrate various aspects of the GUI implemented, forexample, by the embodiments 300 and 310. A display 320 includes controls322 for selecting the categories of metrics (or, in some embodiments,the metrics) for display. A display area 324 displays the selectedcategory of metrics and/or the selected metrics. In an embodiment, thedisplay area 324 includes a sub-area corresponding to each of themetrics. In another embodiment, the display area 324 includes furthercontrols (e.g., controls 326, 328) for selecting which metric to displayin the display area 324.

A summary of the metrics may be displayed in one part 330 of the displayarea 324, in an embodiment. The summary may include, for each metric inthe category selected to be displayed, a trend graph 332 for the dataover some period of time, a value 334 of the result associated with themetric, and an indication 336 of how the result compares to theappropriate benchmark(s). In the exemplary display 320, the indication336 is depicted as a continuum having three ranges 338A-C, a bar 340indicating the range of the result over the depicted period of time, anda current result 342 corresponding to the most recent value of theresult for the metric. In an alternate embodiment, the indication of howthe result compares to the appropriate benchmark(s) may take the form ofshading or other indicators on the trend graph 332.

The display area 324 may also include an organizational analysis of theKPIs in a second part 344. The organizational analysis may display theresult for the KPI according to one or more parts of the organization asa whole showing, for example, the indemnity conversion rate amongdistributors, retailers, and manufacturers within the organization, asdepicted in FIG. 8. In FIG. 8, the organizational analysis is presentedas a pie graph 348. In an embodiment selecting an area corresponding toone of the parts of the organization may cause the display to show thedata corresponding to the area. For example, selecting segment 350 ofthe graph 348 corresponding to the distributors may cause the display toshow the claim data corresponding to claims within the distributor partof the organization, which claims are part of the conversion ratecalculation.

Further, the display area 324, by way of controls 346 may allow the userto select whether to view the data according to the body part injured,the cause of the injury, or the nature of the injury. Additionalcontrols (not shown) may provide the user with the ability to specifydifferent time periods for which data may be generated and/or displayed.Selecting a data point in one of the graphs may cause the display toshow the set of data corresponding to the data point. For example, thedisplay 320 illustrates a monthly average indemnity cost for each offour different causes in a graph 352. Selecting (e.g., with an inputdevice) the data point 354 corresponding to the average indemnity costfor February of claims caused by being struck or injured by somethingmay cause the data corresponding to the data point to be displayed.

Throughout this specification, plural instances may implementcomponents, operations, or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may he performed concurrently, and nothing requires that theoperations be performed in the order illustrated. Structures andfunctionality presented as separate components in example configurationsmay be implemented as a combined structure or component. Similarly,structures and functionality presented as a single component may beimplemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter herein.

For example, the network 104 may include but is not limited to anycombination of a LAN, a MAN, a WAN, a mobile, a wired or wirelessnetwork, a private network, or a virtual private network. Moreover,while only two client devices 102 are illustrated (only one in detail)to simplify and clarify the description, it is understood that anynumber of client device 102 are supported and can be in communicationwith the server 106.

Additionally, certain embodiments are described herein as includinglogic or a number of components, modules, routines, applications, ormechanisms. Applications or routines may constitute either softwaremodules (e.g., code embodied on a machine-readable medium or in atransmission signal) or hardware modules. A hardware module is tangibleunit capable of performing certain operations and may be configured orarranged in a certain manner. In example embodiments, one or morecomputer systems (e.g., a standalone, client or server computer system)or one or more hardware modules of a computer system (e.g., a processoror a group of processors) may be configured b software (e.g., anapplication or application portion) as a hardware module that operatesto perform certain operations as described herein.

In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that is permanently orsemi-permanently configured (e.g., as a special-purpose processor, suchas a field programmable gate array (FPGA) or an application-specificintegrated circuit (ASIC)) to perform certain operations. A hardwaremodule may also comprise programmable logic or circuitry (e.g., asencompassed within a general-purpose processor or other programmableprocessor) that is temporarily configured by software to perform certainoperations. It will be appreciated that the decision to implement ahardware module mechanically, in dedicated and permanently configuredcircuitry, or in temporarily configured circuitry (e.g., configured bysoftware) may he driven by cost and time considerations.

Accordingly, the term “hardware module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured (e.g., hardwired), or temporarilyconfigured (e.g., programmed) to operate in a certain manner or toperform certain operations described herein. As used herein,“hardware-implemented module” refers to a hardware module. Consideringembodiments in which hardware modules are temporarily configured (e.g.,programmed), each of the hardware modules need not be configured orinstantiated at any one instance in time. For example, where thehardware modules comprise a general-purpose processor configured usingsoftware, the general-purpose processor may be configured as respectivedifferent hardware modules at different times. Software may accordinglyconfigure a processor, for example, to constitute a particular hardwaremodule at one instance of time and to constitute a different hardwaremodule at a different instance of time.

Hardware modules can provide information to, and receive informationfrom, other hardware modules. Accordingly, the described hardwaremodules may be regarded as being communicatively coupled. Where multipleof such hardware modules exist contemporaneously, communications may beachieved through signal transmission (e.g., over appropriate circuitsand buses) that connect the hardware modules. In embodiments in whichmultiple hardware modules are configured or instantiated at differenttimes, communications between such hardware modules may be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module may perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further hardware module may then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules may also initiate communications with input oroutput devices, and can operate on a resource (e.g., a collection ofinformation).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e,g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods or routines described herein may be at leastpartially processor-implemented. For example, at least some of theoperations of a method may he performed by one or processors orprocessor-implemented hardware modules. The performance of certain ofthe operations may be distributed among, the one or more processors, notonly residing within a single machine., but deployed across a number ofmachines. In some example embodiments, the processor or processors maybe located in a single location (e.g., within a home environment, anoffice environment or as a server farm), while in other embodiments theprocessors may be distributed across a number of locations.

The one or more processors may also operate to support performance ofthe relevant operations in a “cloud computing” environment or as a“software as a service” (SaaS) For example, at least some of theoperations may be performed by a group of computers (as examples ofmachines including processors), these operations being accessible via anetwork (e.g., the Internet) and via one or more appropriate interfaces(e.g., application program interfaces (APIs)).

The performance of certain of the operations may be distributed amongthe one or more processors, not only residing within a single machine,but deployed across a number of machines. In some example embodiments,the one or more processors or processor-implemented modules may belocated in a single geographic location (e.g., within a homeenvironment, an office environment, or a server farm). In other exampleembodiments, the one or more processors or processor-implemented modulesmay be distributed across a number of geographic locations.

Some portions of this specification are presented in terms of algorithmsor symbolic representations of operations on data stored as bits orbinary digital signals within a machine memory (e.g., a computermemory). These algorithms or symbolic representations are examples oftechniques used by those of ordinary skill in the data processing artsto convey the substance of their work to others skilled in the art. Asused herein, an “algorithm” is a self-consistent sequence of operationsor similar processing leading to a desired result. In this context,algorithms and operations involve physical manipulation of physicalquantities. Typically, but not necessarily, such quantities may take theform of electrical, magnetic, or optical signals capable of beingstored, accessed, transferred, combined, compared, or otherwisemanipulated by a machine. It is convenient at times, principally forreasons of common usage, to refer to such signals using words such as“data,” “content,” “bits,” “values,” “elements.” “symbols,”“characters,” “terms,” “numbers.” “numerals,” or the like. These words,however, are merely convenient labels and are to be associated withappropriate physical quantities.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or a combination thereof), registers, or othermachine components that receive, store, transmit, or displayinformation.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. For example, some embodimentsmay be described using the term “coupled” to indicate that two or moreelements are in direct physical or electrical contact. The term“coupled,” however, may also mean that two or more elements are not indirect contact with each other, but yet still co-operate or interactwith each other. The embodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including;” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, articles or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present). A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of the “a” or “an” arc employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the description. Thisdescription should be read to include one or at least one and thesingular also includes the plural unless it is obvious that it is meantotherwise.

Still further, the figures depict embodiments of a system and method forgenerating risk profile reports, and of a system and method fordisplaying data associated with a risk profile, for purposes ofillustration only. One skilled in the art will readily recognize fromthe following discussion that alternative embodiments of the structuresand methods illustrated herein may be employed without departing fromthe principles described herein.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs for thedisclosed systems and methods through the disclosed principles herein.Thus, while particular embodiments and applications have beenillustrated and described, it is to be understood that the disclosedembodiments are not limited to the precise construction and componentsdisclosed herein. Various modifications, changes and variations, whichwill be apparent to those skilled in the art, may be made in thearrangement, operation and details of the method and apparatus disclosedherein without departing from the spirit and scope defined in theappended claims.

We claim:
 1. A memory device storing machine-readable instructions, theinstructions executable by a processor to cause the processor to:retrieve a first set of data from a database, the data includinginformation about a plurality of insurance claims; perform an analysisof the first set of data to determine a first result associated with afirst key performance indicator; obtain a first set of benchmark valuescorresponding to the first key performance indicator; compare the firstresult to the first set of benchmark values to determine therelationship of the first result to the set of benchmark values; andgenerate a risk profile report for output to the user that includes therelationship between the first result and the first set of benchmarkvalues wherein the key performance indicator is one of the groupconsisting of: a percentage of workers compensation claims that includetemporary total disability payments; an average number of days pertemporary total disability claim; an average value of indemnity claims;a medical-to-indemnity conversion rate; a claim closure, rate forworkers compensation claims; an average time between a date of loss, anda date reported to a third party; a percentage of total claim paymentsattributable to medical costs; a percentage of medical costsattributable to pharmacy costs; a PPO penetration rate; a percentage ofclaims litigated; a percentage of total claim payments attributable toexpenses; a percentage of total claim payments attributable to legalexpenses; a trend relationship related to an actuarially based claimfrequency rate; a variance related to an incidence rate of OccupationalSafety & Health Administration (OSHA) claims; a variance related to alost work date rate; and a loss rate calculated based on claim frequencyand claim severity.
 2. The memory device according to claim 1, whereinthe instructions further cause the processor to graphically depict therisk profile report on a display device.
 3. The memory device accordingto claim 1, wherein the instruction s are further executable by theprocessor to cause the processor to: associate with the first keyperformance indicator a risk indication according to the comparison ofthe first result to the first benchmark value; and depict on the riskprofile report the first key performance indicator and the riskindication associated with the first key performance indicator.
 4. Thememory device according to claim 3, wherein the risk indication isassociated with a color.
 5. The memory device according to claim 4,wherein the color associated with the risk indication is selected fromthe group consisting of red, yellow, and green.
 6. The memory deviceaccording to claim 3, wherein the risk indication is associated with anumerical indication, arrow, or icon.
 7. The memory device according toclaim 3, wherein the risk indication is a value associated with a cellin a spreadsheet.
 8. A memory device according to claim 3, wherein theinstructions are further executable by the processor to cause theprocessor to perform an analysis of one or more second sets of data todetermine one or more second results associated with one or more secondkey performance indicators; obtain one or more second sets of benchmarkvalues, each of the one or more second sots of benchmark valuescorresponding to a respective one of the one or more second keyperformance indicators; compare each of the one or more second resultsto the respective one or more second sets of benchmark values; associatewith each of the second one or more key performance indicators arespective risk indication according to the respective comparison of theone or more second results to the one or more second benchmark values;and include in the risk profile report each of the second keyperformance indicators with the respective one or more associated riskindications.
 9. The memory device according to claim 8, wherein eachrisk indication is associated with a color.
 10. The memory deviceaccording to claim 9, wherein the color associated with each riskindication is selected from the group consisting of red, yellow, andgreen.
 11. The memory device according to claim 8, wherein the riskprofile report comprises a chart having a row that corresponds to eachkey performance indicator and columns that correspond to reported dataassociated with each key performance indicator.
 12. The memory deviceaccording to claim 11, wherein one of the columns of the risk profilereport includes the risk indication associated with each key performanceindicator.
 13. A memory device storing machine-readable instructions,the instructions executable by a processor to cause the processor toretrieve one or more sets of data from a database, the data includinginformation about a plurality of insurance claims; perform an analysison each of the one or more sets of data to determine a result for eachset of data, the result being associated with a key performanceindicator for each set of data; obtain one or more sets of benchmarkvalues, each of the one or more sets of benchmark values correspondingto a respective one of the one or more key performance indicators;compare each of the one or more results to the respective one or moresets of benchmark values; associate a respective risk indication,according to the respective comparison of the one or more results to theone or more benchmark values, with the key performance indicator foreach set of data; and generate a risk profile report for output to theuser that includes the risk indication associated with the keyperformance indicator for each sot of data; wherein at least one keyperformance indicator is selected form the group consisting of: apercentage of workers compensation claims that include temporary totaldisability payments; an average number of days per temporary totaldisability claim; an average value of indemnity claims amedical-to-indemnity conversion rate; a claim closure rate for workerscompensation claims; an average time between a date of loss and a datereported to a third party; a percentage of total claim paymentsattributable to medical costs; a percentage of medical costsattributable to pharmacy costs; a PPO penetration rate; a percentage ofclaims litigated; a percentage of total claim payments attributable toexpenses; a percentage of total claim payments attributable to legalexpenses; a trend relationship related to an actuarially based claimfrequency rate; a variance related to an incidence rate of OccupationalSafety & Health Administration (OSHA) claims; a variance related to alost work date rate; and a loss rate calculated based on claim frequencyand claim severity.
 14. The memory device according to claim 13, whereinthe instructions further cause the processor to graphically depict therisk profile report on a display device.
 15. The memory device accordingto claim 13, wherein each risk indication is associated with a color.16. The memory device according to claim 15, wherein the colorassociated with each risk indication is selected from the groupconsisting of red, yellow, and green.
 17. The memory device according toclaim 13, wherein the risk profile report comprises a chart having a rowthat corresponds to each key performance indicator and columns thatcorrespond to reported data associated with each key performanceindicator.
 18. The memory device according to claim 17, wherein one ofthe columns of the risk profile report includes the risk indicationassociated with each key performance indicator.